Secured system for accessing application services from a remote station

ABSTRACT

A secured system for accessing application services from at least one application program where at least one client station having low-level application independent logics stored therein and at least one controller for controlling the low-level application independent logics, the low-level application logics including a user interface logic, a device control logic for controlling devices, a file system logic, and a communication interface logic, and wherein at least one client station has means to restrict access to said application independent logics, at least one application server having high-level application logic stored in a server device for running at least one application program, the server device being coupled to said at least one application server and low-level interface between said at least one client station and said at least one server for connecting said at least one client station to said at least one application server, wherein upon accessing by said at least one client station, said at least one application server runs at least one application program which selectively controls said low-level application independent logics for controlling devices of said a t least one client station and accessing data of said at least one client station without permanently storing said at least one client station data in said at least one server. There is also a description of a secure operating system and method and a secured system and method of construction of a computer system as well as description of system and method of how to preserve a running current state of an application program for security and relocation purpose.

[0001] The present application is a continuation application ofapplication Ser. No. 09/280,264 filed Mar. 29, 1999, which is acontinuation in part of application Ser. No. 08/769,493 filed Dec. 18,1996.

FIELD OF THE INVENTION

[0002] The invention relates generally to a reciprocal client-servernetwork system and, more particularly, to a secured system and methodfor obtaining application services (i.e., embeddedservices/applications) from a server and for delivering such services tothe requesting client/desktop device, where the service's applicationlogic (high-level presentation, business and database logic) isindependent from the client's low-level operating system and I/Operipheral devices and where client device has means to restrict accessto its resources.

BACKGROUND OF THE INVENTION

[0003] As we are looking forward to year 2000 and beyond, a questionarises. How will computing look in the future? The trends we have seenare obvious; more powerful chips are being released every few months,while software development struggles to keep up with the hardware butnever does. Of course, we now have a slightly new twist, i.e. the newfound popularity of Internet, the web, and JAVA® code (developed bySUN®). For instance, with respect to the web, typically a serverdownloads code (e.g. graphics, JAVA applets) to a general purposecomputer, and the computer's browser software interprets the codes fordisplay. However, interpreting and downloading the code takessignificant time.

[0004] Some have said that JAVA (being platform independent) has finallybrought a tool to the computer market to break the major chip andoperating system (OS) dominance which have developed in the desktopindustry, via INTEL® and MICROSOFT®, respectively. However, differentsoftware vendors are creating their own JAVA extensions, such that JAVAis losing its portability. For example, MICROSOFT has developed its ownJAVA dialect/interpreter, MS J++® with extensions specific to theMICROSOFT web browser EXPLORER® and other related MICROSOFT technology,such as ACTIVE-X®.

[0005] Further, we have seen neither INTEL nor MICROSOFT despair aboutweb development, i.e., they do not see the currently available Internettechnologies as able to threaten their respective monopolies, as “IntelInside” will continue to power general purpose PCs and MICROSOFT's OSswill continue to manage them, while its MICROSOFT web-browser EXPLORER®now supports JAVA code. Further, MICROSOFT's proprietary ACTIVE-X orActive Server Pages (ASP) technology is a JAVA competitor which may yetderail the industry's effort to use open standards. Accordingly, INTEL'sand MICROSOFT's dominance remains the same.

[0006] It has been predicted that computing, especially networkcomputing, will change so drastically in the near future that nocompany/vendor would be able to dominate any market but the currentefforts by many software vendors to “extend” the JAVA standards isputting that prediction in doubt. As JAVA applets get developed,incorporating non-standard extensions will eventually cause theemergence of another yet another dominant JAVA applet supplier. At thispoint, there is little doubt it is going to be the current softwaregiant MICROSOFT. By modifying its proprietary operating systems, likeWindows 95/98/2000 and Windows NT to more effectively process eitherJAVA applets with proprietary extensions or ACTIVE-X objects, or evenintroducing a completely new Java-like language MICROSOFT once againwill dominate software application development by divide and conquerapproach.

[0007] General purpose computing on the desktop, i.e., desktops having astandard OS (such as Windows 98/95®) and a microprocessor (such as thePentium® chip), has to be replaced by a system which is less expensiveto own and maintain but at the same time does not short-change the userby taking away features which we all have come to expect from our PCs,such as flexibility, extendibility, high-security, ease-of-use, andreasonable cost of initial ownership to enable the software and hardwareindustry to proceed forward in new and creative ways.

[0008] Foreseeable disadvantages of the standard general purpose PC orNetwork Computers (NC), with respect to the networks and JAVA, includethe following. JAVA applications will increase in complexity, thereforerequiring faster processors and greater memory in the desktop unit torun them (the same problem which PCs have always had) again forcing theuser into a never-ending spiral of hardware and software upgrades.Currently, JAVA applets are four to five times slower than compiledcode, requiring more powerful processors to get similar performance ascompared to an application that runs native binary code. Further,converting applications from another high-level language to JAVA (oreven from C++) is a very expensive, labor-intensive effort, so that itis no wonder that legacy COBOL applications are still often used inbusiness instead of being rewritten in another language. If it is takingbillions and billions of dollars to fix a small Y2K problem it wouldtake trillions of dollars to rewrite the huge number of existingapplications in some Java-like language and even more to upgrade all thehardware.

[0009] It is also a concern that the computer's writable resources, e.g.a hard drive, can be compromised or damaged by rogue JAVA applets oryour computer resources can be used in many insecure and unauthorizedways. On the other hand, if the computer has no writable resources, thenthe user typically keeps his or her files in remote locations, e.g. on aremote file server, thereby making the user's data files a security riskwhich no company can afford. An example of a computer having no writableresources is the proposed Network Computer “NC” (a joint effort byAPPLE®, NETSCAPE®, IBM®, ORACLE® and SUN®). Although some effort hasbeen made to add digital certificates to Java applets, the companiesissuing those certificates are NOT willing to accept any legalresponsibility for fraud and do not have the resources to verify if theyissue certificates to the right person or company. Therefore thepotential for impersonation, fraud and loss of business data to damageor copying is enormous with Java, Active-X or other Java-likeapproaches.

[0010] A typical network system having server-client architecture, whichcan be utilized in the present invention, would include a network havingat least one server connected to at least one client over a sharedtransmission medium. The network is applicable to supporting thetransmission of data on a local area network (LAN) or on a wide areanetwork (WAN).

[0011] A typical server, which can be utilized in the present invention,may vary substantially in its architecture. It may be a uni- ormulti-processor machine, a PC or a mainframe, a workstation from a majormanufacturer or a proprietary technology based computer, etc. It mayeven be a special function device without any OS or software. The servershould be able, however, to function in a predefined way or to runwhatever software that the company which owns the server needs to run onit. It should also be able to comply with standard transport protocol,such as tcp/ip usd by the Internet or other transport protocols used onwireless or wired LANs.

[0012] The server used in the present invention may have its own filesystem for storing service-related files and data or server may strictlybe a computational server whose software is loaded from the file systemof another server, i.e., a file server or file system of super-client(neither shown), which is preferable for security reasons. If the serverloads its software from a super-client or a file server then the serverneeds to run a program/application loader which can accept applicationcode from some pre-determined port and load it into memory forexecution. A security protocol and loading protocol would need to beestablished between a super-client and the server to insure that thesuper-client is authorized to load software applications into theserver. If the computational server runs the booted programs solely fromRAM, then it would not have access to its local file system after thesoftware is loaded into its main memory (RAM).

[0013] There are three basic conventional computing architectures. Atwo-tier architecture can be either a set of terminals attached to acentral computer or a set of computational clients attached to a centralfile server. In addition to the described two-tier computingconfigurations, a three- or N-tier computing configuration may also beutilized.

[0014] Conventionally, in a first major configuration, the clientstations are essentially “dumb” terminals connected to a central servervia a transmission medium. The central server contains the client users'data and the application/program code. Further, the central serverexecutes all the programs for its clients.

[0015] Substantially all of the application logic (i.e., presentationlogic, business logic, and database logic) is resident within thecentral server. Such application logic (presentation, business,database) includes any program logic concerned with delivering and/orexecuting the application service. Note, however, that each client mayharbor some low-level graphical interface logic such as X11 protocol.These clients are diskless and perform no general computational tasksand do not usually have any devices other than the display which areaccessible to applications. Further, the database (file system) logic onthe server is shared among the clients. An example of such a system is aset of X-terminals attached to a central computer/server.

[0016] In a second major configuration, the central server contains boththe program code and the file system which the clients use, as with thefirst configuration, but does not execute any applications. Instead, theapplications are downloaded into each requesting client through thenetwork and run on each client. The client, however, continues using thecentral server as the client database/file system source. The clients inthis configuration are usually diskless but do contain powerful CPUs,such as by SPARC®, MIPS® and ALPHA®. Although all of the presentation,business and database logic (while running) reside on the client, thefile system is located on the central server and is shared among theclients. An example of the second configuration include a LAN with acentral database such as ORACLE, Informix or Sybase running on an IBMAS/100 file server and set of diskless desktop machines like SUN orRS6000 workstations using a central file server to get their programcode and data.

[0017] Further, the proposed NC (Network Computer) is similar to thesecond conventional configuration, except that instead of loading nativemachine code onto a client, JAVA code is sent to be either interpretedor compiled on-the-fly into native code at the client station. That is,the JAVA code is either interpreted by the browser software on theclient or the browser first compiles the JAVA code, then runs it. Theobvious problems with this solution are that interpreted code andcompilation is slow, and as the complexity of JAVA code increases, theCPU/memory combination of the NC or general purpose PC/browsercombination would also have to increase in computational power andmemory size to accommodate the growth. Further, JAVA code would arriveto the desktop in source form making it very difficult to determinewhether malfunctions or bugs are associated with the JAVA applet or thebrowser software itself.

[0018] In addition, since the JAVA code is supplied to run on theclient, an application foreign to the client is accepted which maypotentially damage the PC's writable resources by malice or mistake(e.g., by utilizing security holes in the browsers) or utilize resourceson the client which the client user may not want to be accessible.Further, the NC fails to protect the user's private data from otherclients since it lacks local storage and all client data has to residein a central location. JAVA also makes copyright enforcement anextremely difficult task for the software vendors. Since JAVA appletshave absolutely no protection from being copied by the client/usermachine, as they are delivered in source form or easily decompilablebyte code.

[0019] In a third conventional configuration, a three- or N-tiercomputing network is employed. Such a configuration is currently beingutilized by Forte Technologies. They offer programming tools todecompose client-server application into presentation logic which runson each client, business logic which runs on the central server anddatabase logic which runs on a file server (not shown). However, thebusiness and database logic may run on the same physical server. As withthe first and second configurations, the client's database/file systemlogic is stored remotely from the client, as it is shared among theclients, and thus poses a security risk. Since the presentation logicruns on the client, this system is also faces with the problem ofconstant upgrades and high maintenance costs of the client stations.Another great problem in this model is that application codes have to bewritten specifically to one software vendor's implementation of theN-tier network and a user is typically forced to license and distributeparts of the system to run his own applications.

SUMMARY OF THE INVENTION

[0020] It is therefore an object of the present invention to overcomethe disadvantages of the prior art.

[0021] There is provided a system and method of accessing applicationservices from selected application programs, stored and run on a remotecompute-server, while the application program utilizes the clients'operating-system-level services such as storage devices for itspermanent storage requirements and other devices for other services.

[0022] At least one remote server uses the client as a peripheral devicefor the purpose of I/O interfacing to the client's keyboard, mouse,monitor, file system or any other client-attached peripheral device andfor controlling those attached devices.

[0023] In particular, the system includes at least one client station,each having user interface (e.g., a graphical user interface (GUI)) andfile I/O logic stored therein and at least one controller circuit (e.g.,a digital signal processor (DSP)) for controlling the client's I/Operipheral devices. The file I/O logic is capable of storing andretrieving data corresponding to the application programs and otherwiseperform low-level file control operations on the file system andspecifically on the device files. Further, the controller operates theuser interface, device control, communication interface and file I/Ologics.

[0024] In addition, the system includes at least one specialized remoteapplication server. Each server includes high-level application logicstored therein for running the corresponding application program orstored in a corresponding file server. A low-level interface (e.g., anoperating system service interface (OSSI)) establishes a common protocolfor connecting each client to each server. OSSI protocol insulateshigh-level application logic from direct access to the underlyingoperating system, thus allowing a high-level application to obtain OSSIservices from different operating systems or from special consoledevices which understand OSSI protocol. OSSI makes it possible for ahigh-level application to use OS-level services on a remote clientstation separated by a network.

[0025] In operation, upon initiation by a client, a selected serverspawns a selected application running thereon and selectively accesseslogics of the client station to control the file system, devices, userinterface and communication interface and to access the correspondingdata of the requesting client. The client station should include somemeans to refuse access by the selected application running on a serverto any specific logic or a group of logics based on the application andany other data available to the client station. Thus, the client acts asa peripheral device (a “window on the world”) for the selected serviceapplication running remotely on the server. In turn, the remote serverprocesses the corresponding data from the client (and on behalf of theclient) through the spawned service application without permanentlystoring the data within the server. In other words, the client servesfile systems, screens, keyboards, mouse, other attached devices to aserver, while the server serves to the client application logic andcompute-power.

[0026] In addition, a “directory” service application may be used whichresides on the server such that the client may launch the selectedapplication via the directory service. “Directory” service applicationsmay perform small services directly (e.g., display some textual orgraphical information), refer to another service application on the sameserver, or reference an application service on another server. In thismanner, multiple directory services may be chained together so that theclient user can reference multiple applications by different vendors,residing on different servers. By chaining “directory” serviceapplications in the above manner, a network of various applicationservices can be readily available to the client. A user can “roam” thenetwork of “directory” services until he/she finds the appropriateapplication for this task. In addition, search engines could also beemployed. Once found, an application Internet address and port can berecorded for future use in the client configuration database/file.

[0027] The applications on the remote servers are not dependent on, andthus preferably not written for, any specific client OS. Thus, theapplication logic is separated from the client's low-level “quasi” OSlogic. In other words, the application does not link directly with theclient's kernel-level services (of the OS) to perform the desiredfunctions. Instead, the application prepares a desired “command packet”(representing the desired function and necessary data) by calling anappropriate command function from the server's function library. Thecommand function from the server's library encodes the command packetaccording to OSSI protocol. The command packet is then dispatched to theclient's quasi-OS via the common transport protocol (such as tcp/ip).The client's quasi-OS can recognize the received, OSSI encoded, packetsfor performing the desired I/O or control operations.

[0028] Further, the quasi-OS has the flexibility to tailor its action inresponse to a specific “command packet” according to its own abilitiesor to the abilities of the devices to which it has access. Therefore,specific logical commands from an application may be executeddifferently depending on in what environment the quasi-OS exists. If X11is used for the GUI, then the application will look and feel like an “X”application. Similarly, if another GUI is used (e.g., Windows 95), thenthe application will look and feel like a Windows 95 application.

[0029] This invention differs from all three conventional models,discussed above, in the following major ways. The invention enablesselected, restricted access from the application on the remote server tothe client's, permanent storage facilities, such as the hard drives,CD-ROM drives, tape drives, floppy drives, and any other I/O or otherdevice which may be attached to the client. In other words, the remoteservers perform operations on the client's local data and devices. Thus,the server can process the data from the client; however, the data doesnot reside permanently on the server. At the same time the clientstation is able to limit access to its various logics by the serverdepending on the server, application, and any other data available tothe client station.

[0030] Local data is simply read from or written to various clientstation devices or the client file system as required by the applicationlogic.

[0031] All of the above conventional models employ a centralized filesystem on the server, so that the file system is shared between theclients. Accordingly, a rogue client can gain unauthorized access toanother client's data through the shared file system. The presentinvention, however, does not share a file system among different clientsbut stores client's data in the attached storage devices such that theyare inaccessible (without explicit authorization from the user) to otherclients or servers.

[0032] Further, in the present invention, if more than one client usesthe same application during the same time period, then each client canmake certain files and devices accessible by the application on theserver at the same time which, if the application permits, may enabledistributed cooperative projects between consenting clients, i.e. theconsenting clients may share devices, files and data.

[0033] Illustratively, the invention prohibits running substantially anyapplication logic on the client. While the first conventionalconfiguration with “dumb terminals” does not run any application logicon the terminal it is also unable to provide storage or any devicesother than display and keyboard and it is unable to provide anyoperating system services to an application. The second conventionalconfiguration executes all application logic on the client side, whilethe third conventional configuration executes high-level presentationand business logic on the client. Further, the application depends on ahigh-level interface between the client and server parts of theapplication, and predetermined platform compatibility.

[0034] Since the present invention removes all application logic fromthe client station while the client station still providing operatingsystem services, there is no longer any need to execute any generalpurpose code (application) on the client station. The remote servers arewholly dependent on the connected clients to serve the client's I/Operipheral devices, therefore the servers do not need any hardwaredevices of their own to get the I/O services which the client stationscan provide. Therefore, expensive general purpose processing CPUs arepreferably replaced with inexpensive but powerful controllers, such asDSP chips. Despite the fact that the present invention does not have anyapplication logic on the client station, it feels in its use like ageneral purpose PC that runs the application program, directly on thePC. The inventive client station can connect to many different serversat the same time with each server performing some specializedapplication. A single client station can share many differentapplications/servers (software or hardware) with other client stationsand many applications/servers can share the client station's operatingsystem level services. The inventive client station allows the clientuser to keep his or her private data on their own disk, and it can haveall the common I/O devices attached to it, such as CD-ROM and floppydrives, as well as other peripherals such as printers, plotters and thelike.

[0035] Another major weakness of the above three conventionalconfigurations is the centralized database/file systems. Giving accessto a server's central file system may be a workable solution in thecorporate Intranet environment, where every user is known and verified(although it is also known that many security breaches are orchestratedby insiders) and can be tracked, but fails completely in the anonymousenvironment of the Internet. The present invention does not suffer fromthe same drawback. Since the server application always utilizes the filesystem on the client, the client has no access to the server's filesystem at all and therefore, can do no damage either through malice ormistake. The client merely connects to a port on the server and cantypically only view whether the server is accepting its requests forservices (via an application). In addition, the server (acompute-server) may not have a file system at all to be damaged butinstead, may boot the appropriate application from another server (e.g.,a corresponding file server or super-client). In such a case, the fileserver may disconnect from the compute-server, while the applicationruns within the compute-server's memory (RAM). Special purpose hardwarechips such as ASICs or FPGAs can also be utilized as specializedservers.

[0036] Another advantage of having the file I/O logic locally on theclient is that every client can insure the integrity of its data withbackups and the like. This eliminates a lot of problems for serviceproviders who would otherwise be responsible for keeping the client'sprogram data safe from corruption or intrusion by third parties. One caneasily see that in the Internet arena, it is simply impossible toaccommodate unlimited numbers of users because of simple limitationslike disk space in the server. In the present invention, however, onlythe computational resources are shared, so many more users can beaccommodated. Further, by having a compute-server access local filesystems of its clients, the performance of the server is also improvedsince typically the file I/O in centralized file systems is the“bottle-neck” for (i.e., reduces) computational performance. Since inthis invention the server sees multiple file systems on different clientstations, there is no competition for the limited storage resources orbandwidth by different client stations or applications.

[0037] Further, the application service can be delivered to a new userinstantly, instead of having to set up either security groups or userIDs. (The present invention offers structural security.) In other words,such conventional security is not necessary (unless for billingpurposes) since the client's data can not be accessed withoutauthorization and the server's applications and data can not be copiedor damaged as it is never sent to the requesting clients. Further, eachclient can receive services anonymously since the application data,specific to the client, resides on the client's file system or availablefrom the client station's devices and the client stations do no evergain privileges to access the server file system. The possibility ofreceiving services anonymously is very valuable because of privacyconcerns witch respect to using the internet.

[0038] In addition, although the client serves its file system anddevices, it is the client station which establishes the connection tothe servers. There is no mechanism for the servers to obtain aconnection to a client station unless the client station is activelyseeking to connect. Therefore, a potential intruder has no way to gainentry into the client's file system. So although the client serves itsfiles, devices (i.e. data), it serves them only to servers to which theclient itself connected.

[0039] Preferably, the firmware which runs on the client (stored in ROM)in the present invention is not user-modifiable since no general purposecomputing will be done locally on the client. Accordingly, expensive,power and memory hungry general purpose operating systems (OS) areunnecessary since user programs/processes need not be loaded or managed.Only a small quasi-OS is required to be stored in the firmware, suchthat the authorized server can control all of the client I/O and filesystem. The operating environment is called quasi-OS because it does notload or run user processes as a conventional operating system (OS) does.Of course any part of the client station can be implemented in hardwareas specialized circuits. For example, the graphical user interface,controlled by the quasi-OS, may be based on the X11 protocol, which isin the public domain.

[0040] Since neither conventional general purpose CPUs nor OSs arerequired in the present invention, a client becomes a long terminvestment for the consumer since such client stations could operateadequately for ten years or longer. On the other hand, since the secondand third conventional configurations have either all or part of thebusiness/application logic residing on the client, the user isinvariably forced to upgrade the system to run more complex and fatterapplications. And the central server with “dumb” terminals conventionalconfiguration requires upgrading the servers a lot more often.

[0041] In addition, with respect to the server, the present inventionpreferably curtails common services like telnet, ftp, rsh, rlogin. Theserver is therefore left with specialized application services which donot allow access to command shells. This creates a very secure systemthat is substantially impervious to outside attack, yet flexible enoughto offer services to the anonymous masses of the Internet. Sinceapplications running on the servers are controlled by the server ownerand operating system services are obtained from the client stations, theserver software/hardware is structurally secure from any client station.The server applications enable the client stations to obtain applicationservices without compromising security of the server.

[0042] Lastly, in the present invention, an application program need bedeveloped only once. After the most appropriate hardware is chosen forthe server (it could be designed specifically for the application), theapplication is developed and, instead of selling the software to run ondifferent platforms, the application need only be set up as a servicehaving a common Internet transport protocol, such as tcp (or udp)/ip,and attached to a network. Since the client contains no applicationspecific logic, any application could use the client for accessingdevice, display and file services. The client's quasi-OS has theflexibility to interpret the command packets received from the connectedserver according to its local capabilities, so that if the client has atext-only display, then the quasi-OS will display information in a textmode. If X11 is used, then X functionality would be employed. However,if Windows is the underlying OS, then Windows facilities would beutilized. The look, feel and capabilities of any application will beadapting to the look, feel and capabilities of quasi-OS. At the sametime, the general behavior of quasi-OS would be controlled by theservice applications.

[0043] The client's quasi-OS and the application would be in a symbioticrelationship—the application tells the quasi-OS what to do, and thequasi-OS determines how it should be done. While the quasi-OS, does nothave any useful function or behavior of its own without theapplications, the applications are unable to get anything done withoutthe quasi-OS I/O and control services. All the hardware/OS dependentfunctionality is encapsulated in the “front-end” of the quasi-OS and allthe logic/behavior of an application is encapsulated in the applicationcode. The two cooperate with each other through an OSSI communicationsprotocol (which itself uses an underlying transport protocol). Thus, theapplication never executes any low-level code, instead it “asks” thequasi-OS to perform that operation on its behalf. In other words, thequasi-OS does not perform any operations which have not been requestedby a remote application (exception is file maintenance operations whenrequested by the client user).

[0044] Existing applications which already have been written forspecific platforms, such as UNIX/X and Windows 95/NT, can be easilyconverted by using libraries which utilize the OSSI for generatingcommand packets, while maintaining conventional UNIX/X or Windows APIs(application programming interface).

[0045] In addition, disk space on the client no longer has to be wastedwith hundreds of megabytes of OS files and application code, since onlydata is stored therein. At the same time, the server does not have tostore any user data or make backups. Also, the user no longer has toworry about upgrading his or her application software, since thismaintenance problem completely passes to the software vendors. Further,upgrading is easy for the software vendors since they need to upgradeonly one application per server which they can phase in slowly. Withrespect to companies wishing to purchase application programs, suchcompanies can purchase the inventive servers having pre-installedservice applications which can immediately service hundreds to thousandsof clients. Hardware requirements for the servers can now be drasticallysimplified, since either a CPU (general purpose or specialized) or aspecial processing chip having the appropriate memory in conjunctionwith the network interface (hardware and software) create a usableserver.

[0046] The present invention of reciprocal client-server operation canalso be extended further even into operations of more conventionaloperating systems and computers to improve security, reduce obsolescenceof hardware components, to improve abilities of mobile computing.

[0047] When the concept of private property was moved from the physicalworld to the world of information there was not much thought given toactual enforcement. Theft or destruction of information are not aseasily proven and damages from such actions are difficult to value.Theft of service (where even copying is not done) where absolutely notangible assets are damages or copied is almost impossible to prosecute.Since the actual wealth associated with information or ways to processinformation is entirely dependent on how many times the owner canactually convince someone to either copy the information or use theprocess, it becomes obvious that the idea of private property inrelation to information or processes is not well-defined. And theconventional networks, computer systems and operating systems are notable to grant access to various resources in a refined fashion.

[0048] This inventive system and method based on reciprocalclient-server operation aim to remedy the shortcomings of theconventional computer technology. The ownership of a resource can beunderstood only in the context of its utilization by others. The betterone can control access to a resource the more of an owner one is. Themore precisely one can determine what can be done with a particularresource, the more ownership value can be extracted from a resource.Ownership of a resource, access to which cannot be easily controlled,has no value. An owner's choice with conventional technology is toeither grant nearly full access to enable use or no access at all tomaximize security; neither of those possibilities enhances the value ofa resource.

[0049] The ownership is best determined not by who produced the resourcebut who can enforce how a resource is accessed and used. Therefore oneneeds to have a technical “guard dog” which allows a resource to be usedin a certain way but restricts its use otherwise, i.e. a runningapplication should be permitted to use certain logics and forbidden touse others.

[0050] In conventional computer systems/OSs (operating systems) securityor access to resources is controlled by maintaining user and groupidentity. Particular users or groups of users can own resources whichthey and only they can access. For example, a file can be owned by auser “alex” and alex then has full control over that resource, alex canmodify or use or look at this resource as well as grant permissions toother groups to use this resource. However, the permission system isvery crude and does not allow for any fine-tuning. Alex can, forexample, allow himself the permission to write, read and execute (if itis a program file) but prevent members of his group (group “staff” forexample) from writing into this file and all others who are not membersof his group are not granted access.

[0051] The problems with this type of access control are numerous.Various systems based on user/group access are normally built arounduser passwords, i.e. a particular user has to demonstrate knowledge ofsome key word or a phrase to gain access. Password and key managementare well known and serious problems in computer security, easilyremembered passwords can be easily guessed and random or difficult toremember and data could be lost. If someone else learns of any userpassword then that someone gains full access to all the resources whichare owned by user alex, i.e. the resource can be copied (copyrightviolations, business information can be compromised, etc.), the resourcecan be damaged (loss of business, recovery costs, etc.), or used withoutan appropriate payment (theft of service). A lot of time and money isspent managing group and individual security to tailor access to systemresources with respect to conventional operating systems and computers.In the present invention access to applications can be anonymous sinceany resource coupled to the server is secured from damage orunauthorized copying by the client stations and all access is managed bythe selected application. At the same time any resources coupled to theclient station can accessed and used by applications are used only forthe benefit and on behalf of the client station user and access to suchresources can be tightly controlled by the client station. The clientstation user can use various security profiles for differentapplications to tell the client station software exactly whichoperations, at what time, with what data could be used with whatapplication and server.

[0052] In order to enable maximum access by a maximum number of peoplefor maximum efficiency but at the same time to maintain maximum securityof the resource, access has to be granted on the basis of whichapplication is being used to access the resource, how much thisapplication is trusted, and which specific operations the resource owneris willing to permit on the specific resource (as an owner of a resourceI may be willing to allow liberal append access but completely unwillingto allow anyone to read/write existing data).

[0053] If applications are stored somewhere on a network one can notautomatically assume that they are trustworthy, therefore there is aneed to design security profiles for each application. Whether anapplication is used remotely or actually downloaded into the clientstation the security risk for the client is the same, therefore all theoperating system services provided for an application either via anetwork or directly by an operating system have to be appropriatelyrestricted. A security profile determines which primitive operations (toaccess OS or devices for data and to control) any particular applicationcan use and which specific parameters are allowed for each specificprimitive operation.

[0054] For example, lets say an application wants to open a file. We caneither forbid this operation to this application outright or we canrestrict the file name space to something with which we the users feelcomfortable, i.e.open(“/home/alexo/somewhattrusted/application/*.txt”,“a”). So the onlyfiles this primitive is allowed to open is files within that specificdirectory and that specific extension and only for an “append”operation.

[0055] If it is not dangerous if a resource is read then there is noneed to restrict any primitive operations which may read this resource.If it is not dangerous to allows one to write to a resource (writing tothe screen for example) then the user may decide not to restrict thoseprimitives which write to that resource.

[0056] If a user wants to use an application program on resource whichhe owns, the danger is that not knowing exactly what this applicationdoes internally can lead the user to damaging his own resource orinadvertently allow others either to damage his resources or obtainaccess beyond what was intended. So a user has to be able to restrictaccess not only by general access depending on the user or group butrestrict access by individual application, by individual atomic(indivisible) operation, by time, by date, by file type, by name, byrange of data which atomic operations may use, i.e. various parametersmay be utilized to restrict execution of any individual primitive(atomic operations) logic. Also if a user is unable to restrict whatactions a particular application can do then an application can bemodified (or Trojaned) to violate security of user's resources. Sincesecurity of the conventional systems is based on ownership of a resourceby a used or a group, there is no protection if a user himself or amember of his group runs a corrupted application.

[0057] Since every application has very specific needs, everyapplication's profile can be tailored to reflect the application's needsand the level of trust a user has in the application. A clockapplication may be allowed to access primitive operations which areneeded to display the clock face but would not be allowed to read thekeyboard or access any storage devices or anything else which is notdirectly required. Therefore, if the clock application eitherinadvertently or on purpose is changed to do something else then theuser would be alerted the moment one of the restricted logics isaccessed and the security of the resource would then not be compromised.

[0058] Lets say that an application is a communications application, oneof the primitive operations this application has to do is to reserve aport, the user then can restrict this application to a range of ports ora specific set of ports so that all other ports are always available forthe user.

[0059] Client station includes application independent well defined setof logics which can be implemented as software, firmware/hardware orhardware only. The application independent logics such as file systemlogic, device control logic, user interface logic, communication logicconsist of a finite number of further indivisible logics.

[0060] Each indivisible logic can be selectively accessed andindividually controlled by an application running on a server computer.

[0061] For each application to which said at least one client stationconnects, said client station maintains information about which finitesubset of the entire set of said further indivisible logics said clientwould process for said at least one application and which finite subsetof said further indivisible logics would not be processed. Further foreach indivisible logic, information about which parameters are allowedfor a particular application and which are not permitted is maintained.Depending on how much trust one has for a particular application, i.e.if the application is completely untrustworthy then the client stationmay only allow this application to use those logics which displayinformation on the screen and have no ability to either read or storedata.

[0062] In case a particular indivisible logic is not processed then theclient station notifies the client station user that said applicationprogram running on a server attempted to access and control saidindivisible logic, and then said user can either allow said processingor refuse to allow said processing. If the processing is allowed, thenthe user can choose if such processing is allowed only this time or apermanent permission is granted.

[0063] Therefore, each application which can be accessed by said clientstation would have a profile of privileges stored on each client, saidprofile defining exactly which indivisible logics said application isable to use.

[0064] Therefore, if an application attempts to control/access logicswhich it is not allowed to access then said application is prevented toaccess and control said logics unless the station user explicitlyoverrides such a restriction.

[0065] The client station is also able to prevent access to a finitesubset of said indivisible logics based on logical function of saidlogics, e.g. file system logic can be disabled in its entirety withoutregard to any particular application.

[0066] In addition, for each indivisible logic, the client station canmaintain description of permissible range of values for the data whichis used by the said logic. For example, if the particular logic is afile opening logic then the client station can insure that all the filenames start with some prefix and end with some particular extension. Fornumeric parameters the client station can specify a range of values or aset of values.

[0067] The total set of the indivisible logics (or primitives) issubdivided into subsets by the security threat level (how much damagethis primitive can do) as well as by function. For example, someprimitives may permanently modify the state of the client station; theseare the most dangerous. Some primitives can simply access informationfrom devices or storage which is less dangerous because no physicaldamage can be done by the system, but is very dangerous from the pointof view of business information getting into the wrong hands. The lastcategory is use or abuse of resources without paying for it or being anuisance.

[0068] All the primitives can be further categorized into set (orgroups) by their function, for example primitives which use printers, orprimitives which display on a screen, or primitives which access storagedevices. An individual primitive logic can belong to multiplecategories.

[0069] A user would be able to turn on or off any particular group orset of primitives for use with any particular application. Depending onthe priority of one or the other group overlapping primitives willbehave as the group of the highest priority. A user can also turn on oroff individual primitives as needed as well as determine valid rangesand values for data used by the primitive logics.

[0070] Therefore, said at least one user station includes the means forthe user to create execution profiles for each application used orgeneric profiles for applications of a certain category. The profilesshould include information about which primitive logics and with whatdata can be processed on behalf of said application.

[0071] The technique of controlling access to every individual logic canalso be utilized even if one running an application directly on thegeneral purpose client station by running an application inside amiddle-ware software program which traps accesses to operating systemservices and checks for the security profiles.

[0072] Reciprocal client-server architecture can also benefitconstruction of operating systems by improve OS portability and computersecurity. Operating system software is a main program which runs on acomputer with special privileges (it has full control over all theaspects of the computer hardware) and its function is to controlcomputer hardware as well as arbitrate access to different resourcesbetween multiple applications (which could be either OS applications oruser applications) and between users (if it is a multiple user operatingsystem like UNIX, VMS, or NT). Of course arbitration between users isreally arbitration between applications which the users run.

[0073] Since the conventional construction of this type of softwaremakes this operating system software monolithic, it is very difficult toimplement security measures as far as access to various parts of theoperating system program (kernel) code and memory space. The monolithicconstruction of OS kernel makes the software vulnerable to computerviruses and access by unauthorized parties.

[0074] At the same time, monolithic OS kernel software is very difficultto port to new CPUs since every new type of hardware requiressubstantial human effort.

[0075] In a further aspect of the invention, it is proposed to modifythe way operating system software is designed and operated as follows.

[0076] OS software should be designed preferably as two (2) separate anddistinct (kernels) programs (although it is possible to go further andsubdivide an OS into more pieces, it does not achieve any additionalbenefits and may complicate design rather than simplify). One part ofthe operating system would deal with user interface, input/output,storage and other device dependent tasks and the other part would dealwith loading and managing user processes (applications), providingaccess to the first part's interface by user processes (applications) aswell as arbitrating this access, managing user process's memory,responding to events arriving from the other part of the OS and passingthe appropriate messages/events to various user processes.

[0077] An interface designed for two parts to communicate with eachother is a finite set of primitive, indivisible logics is implemented aspart of device control of the user console by application processes.This set of primitive logics is called operating system servicesinterface (OSSI) and is a protocol which utilizes some standardtransport protocol to affect the actual communication of data packets.Within an operating system designed as two distinct logical programs,the user interface can restrict access to the primitive logics by theother part of the operating system depending on what application isrequesting service.

[0078] So to summarize, this new addition is a separation of OS software(kernel) into two distinct parts. One part is responsible forcontrolling devices on a computer and the other part is responsible forrunning various user processes. The two parts communicate to each otherthrough the OSSI protocol. Since the part which loads and runs userprocesses is peripheral device independent, it can be easily ported toany CPU or specialized processing chip with RAM. By running the twoparts separately on two different computers (or more specializeddevices), connected by a network, it is possible to run userapplications in one place and have their effects manifest themselves onanother machine.

[0079] It is also possible for multiple CPUs of same or differentarchitectures to share operating system services of the devicecontrolling OS kernel via utilizing OSSI protocol.

[0080] Although there are a lot of different hardware architecturesbasically all conventional hardware architectures have several things incommon. A processor with some memory (memory is usually attached throughmemory management unit or MMU), a bus and peripheral devices connectedto said processor via said bus. This type of conventional architectureuses the main CPU to perform computation as well as control said devicesattached via said bus. The entire memory is accessible to the processorand every attached device can be controlled by the processor. Inaddition, the CPU, the memory and all the other devices are usuallyhoused within the same chassis or enclosures. If a CPU or memory need tobe upgraded, it is common that the whole computer is discarded althoughmost of the peripheral devices could perform their task for many yearsto come. It is also very wasteful that there is not a kind ofinexpensive user console hardware which can either connect to a networkand use computational resources of the network as well as being able toconnect to local computational resources securely.

[0081] By running am application on such a conventional hardwaremachine, the application is essentially given full control over all thehardware resources, i.e. there is no easy way to determine whichresources can be accessed and which should be off limits. It is verycommon for computer users to run applications about which said users donot have complete knowledge, therefore enabling viruses and trojan horseprograms to be run on the computer.

[0082] Reciprocal client-server computing architecture is alsoapplicable to designing new type of computer system as follows.

[0083] To reduce obsolescence of peripheral devices and chassis andother hardware components and to maintain high levels of security of allthe IO devices and storage devices, a conventional computing device(conventional computer) should be substituted by a computing deviceconsisting of two separate enclosures (units). The two separate unitsthen interact with each other according to the reciprocal client-serverarchitecture model as discussed earlier in this application.

[0084] The two units do not share either program code memory or datamemory, the interaction between the two units is conducted through theoperating system services interface protocol. This protocol defines afinite number of commands which the user console unit can understand andact upon. The user console unit can also restrict processing of commandsdepending on many various data available to it.

[0085] One enclosure containing all the peripherals like storage, I/O,data acquisition, user interface devices and the second unit containingthe CPU, RAM, devices needed for execution of applications. The twounits would be physically connected by some network or wire or a bus(like SCSI for example or a wireless connection) to exchange informationvia using OS services protocol. By separating a computer into twodistinct units one can substantially reduce obsolescence of either ofthem. Since biological abilities to see, hear, feel, smell, etc. do notevolve quickly, the front-end unit designed to interface with the usercan be used for a very long time, while the computational unit can beupgraded as needed. It also would be possible to change the CPU unit oreven have multiple (with different architectures) CPU units attached atthe same time and running applications at the same time. The distinctionbetween a local application running on your “desktop” and an applicationrunning remotely elsewhere then disappears as in both cases the sameoperating system services protocol would be utilized to enable anapplication to use the front-end user console operating system services.

[0086] By using a common transport protocol (like TCP/IP) to connectvarious devices within a single computer (or physically local set ofdevices) one can extend the life-time of computer equipment and makethese equipment more general, i.e. easy and inexpensive processorupgrades, the same front-end unit can talk to CPUs on the internet,intranet, extranet, or the CPU on your desk.

[0087] Networks ate not 100% reliable. In fact, communications betweencomputers fail on a regular basis. If the application being run over anetwork does not take a long time to execute, then one can always rerunthe application. If, however, failure of a network would cause a loss oftime and money for rerunning the application, then there is a need topreserve the current state of an application at regular intervals oftime and when some other special events occur. If one of the machines(ordevices) running a part of an application needs to be powered down formaintenance, we want to be able to relocate that part of the applicationto another machine or at least preserve its state so that it can berestarted later. Most companies and individuals do not have access tofault tolerant technology for either their computers or the network; andif the internet is used then reliability of your connections depends onthird parties and is out of your control.

[0088] Therefore to overcome the problems with network failures and theneed to move parts of distributed applications/programs from onephysical machine to another, the following inventive system and methodare proposed. It is proposed that various parts of a network applicationcollect various data about their internal state. These data collectioncan be triggered on a regular basis by a timer and/or by some event likereceiving a communication or signal from another part of a networkapplication or operating system. Upon receiving some communicationinstructing a particular part of a network application to preserve itsstate, the application proceeds to create a data object with completeinformation about its internal state. The application for example couldpreserve its stack space, program pointer and all other data whichcorresponds to its current state, it then may possibly compress thisdata, it may possibly encrypt this data, and then sends this data to anagreed location. The file with the data representing the state of theapplication is a check-point file. The application then may continue, ormay be suspended, or it may be terminated so that it can be restarted ata later time.

[0089] In case of a reciprocal client-server architecture as describedin the parent application entitled “Secured System for AccessingApplication Services from a Remote Station” the application running onan application server collects data about its internal state and thensaves this data by transferring it to the client station attached to itfor future use. Each client station receives a state of an applicationspecific to the client station's data and state of the application atthe time of check-point creation.

[0090] Elaboration on Encrypted Check-point Files.

[0091] To preserve the state of the application from time to timepreferably on a regular basis (based either on timers or other eventslike user's input) information about the state of an application can becollected and transferred to the client (desktop) machine forpreservation. If an application server crashes or the network is downthen the work performed so far by the application can be preserved. Whenthe client machine later is able to reconnect to the application, theexistence of a check-point file can be detected and the application canbe restarted from the last check-point. A user can potentially forcecreation of a check-point file in order to transfer his desktop toanother physical location and restarting the application from the samepoint. Note that under our model, there is no need for the applicationto continue to run on the server wasting memory and computationalresources (while the desktop is disconnected). Therefore a user can runhis application to a certain point, force the application to preserveits state, fly 3,000 miles and then reconnect to the same applicationand restart it from the same place. If the application is idle for along time (the appropriate period of time can be determined by theserver's administrator) the application can be directed to collect itsstate information, to send the state information (check-point data)somewhere else for preservation and then terminated in order to preservethe server's resources for active applications. Of course in thereciprocal client-server architecture network the state informationwould be sent to the client station for preservation either in itsmemory or some storage device.

[0092] Check-point files have to be encrypted by the application serverto prevent tampering by a rogue user. The server encrypts theapplication state information(file) with a symmetric key and neverreveals to another party (especially the client) what that key is.Therefore, only the same server (possibly only the same application) isable to decrypt the information to restore the original applicationprocess to the identical state.

BRIEF DESCRIPTION OF THE DRAWINGS

[0093] The following detailed description, given by way of example andnot intended to limit the present invention solely thereto, will best beunderstood in conjunction with the accompanying drawings in which:

[0094]FIG. 1 schematically illustrates a two-tier network having aserver, transmission medium and a plurality of clients;

[0095]FIG. 2 schematically illustrates a reciprocal client-servernetwork having a plurality of compute-servers, a file server, containingapplication program code, attached to one of the compute-servers,transmission medium and a plurality of clients in accordance with thepresent invention;

[0096]FIGS. 3A and 3B are flow charts showing the general steps foraccessing and using an application on a server from a remote client;

[0097]FIG. 4 schematically illustrates a conventional computing device(computer) with a single bus for communications between peripheraldevices and CPU and memory. Random Access Memory is shared by all thedevices and CPU to perform their tasks;

[0098]FIG. 5 schematically illustrates a computing device constructedfrom two distinct functional blocks, user console device block andcomputation/application block. User console device block has a separatecontroller for performing its tasks and its own private memory, whileCPU/application block has its own processor(s) and its own privatememory to run applications and processes in accordance with the presentinvention;

[0099]FIG. 6 shows separation of an operating system into two parts,user console part (2) and process kernel (5) connected via operatingsystem services interface (4);

[0100]FIG. 7 shows a conventional monolithic operating system in whichan application could potentially gain full access to all the resourcescontrolled by the OS kernel; and

[0101]FIG. 8 is a schematic diagram illustrating a system for preservingstate of an application program by storing check-point data.

DETAILED DESCRIPTION OF THE INVENTION

[0102] Referring to FIG. 2, the inventive system 11 comprises aplurality of specialized application servers 12, 13, 17 connected to aplurality of clients 15 over shared transmission medium 18. File server16 contains application program code for application server 17. As withnetwork 10 of FIG. 1, the system 11 is applicable to supporting thetransmission of data on a LAN or WAN system. In general, each clientserves its monitor, keyboard, mouse, file system, and other I/O anddesktop attached peripheral devices. The servers serve theircorresponding compute-power, application logic and control the I/O andother devices of the clients.

[0103] Each server is typically supported by an independent vendor torun their software application programs, as desired. For example, server12 may be supported by vendor A for running word processingapplications, while server 13 may be supported by vendor B for runningengineering type applications. Further, one server may support serviceapplications from different companies but which run similarapplications. That is, server 12, e.g., may be supported by a serviceprovider which will host multiple software vendors' applicationsrelating to spreadsheets. Of course, service applications running on thesame server need not be similar at all.

[0104] Server 16 is shown connected exclusively to server 17 and acts asa file server. File server 16 stores and boots the selected applicationprogram, as instructed by computational server 17. For example, fileserver 16 may be considered a so-called super-client that injects theselected application to compute-server 17 and then disconnects fromserver 17. This setup is preferable, as it adds a level of security froma client that connects to server 17 with the intention of corrupting theapplications.

[0105] Each client 15 is preferably not a general purpose PC but aninexpensive and highly robust data-acquisition device. Thus, a clientdoes not require a conventional CPU, such as a Pentium, PowerPC or Alphachip. Nor does a client require a conventional OS, such as MS-DOS® orWindows 95. Instead of a conventional general purpose CPU, inexpensivebut powerful controller circuits will be utilized for controlling thestorage devices and other I/O hardware. An example of a possiblecontroller is a TI TMS320C4× or C3×DSP chip. The controller or aplurality of controllers will control the client file system (file I/Ologic) and low-level graphical user interface logic (e.g., GUI). Forexample, each client may have a separate controller chip for the filesystem/disk controller block, the communication block and thedisplay/human interface block of the client, or one DSP control maycontrol all three blocks.

[0106] Since the functions of the file I/O and graphical interface logicare well-defined and understood and do not have to be changed fordifferent applications, they can be highly optimized in machine languagefor the highest speed, and will be provided as firmware in the clientstation's ROM, rather than software as is conventional (sinceconventional OSs are programmable). In fact, most of the functions couldbe cast in hardware like ASICs. It should be understood that generalpurpose computers will also work with the present invention (with littleor no modifications), such that existing owners of PCs can access anyspecialized server to spawn a selected application, as desired. In sucha case, the quasi-OS is replaced with the front-end “compute-browser”which has to be ported to the general purpose computer's OS (Windows95/NT, UNIX, OS2, and the like) like any other program and runs as auser process under the regular operating systems mentioned above. This“compute-browser” would then utilize the host OS resources to controllocal devices on behalf of the remote service applications. Further,non-specialized servers having conventional application programs storedthereon may be utilized via the use of a “directory” serviceapplication, while the directory service application would provide theservice to the client but may use one or more conventional programs toperform its tasks. Conventional applications can also be easily modifiedinto service applications by recompiling and linking them with newstartup code and new I/O and OS libraries.

[0107] Referring back to the specialized clients, instead of aconventional OS, a low-level “quasi”-OS, such as one whose graphicaluser interface is based on the X11 protocol (X11 is in the publicdomain), modified for data compression and encryption, will be stored inthe ROM of each client. The quasi-OS essentially acts as a driver toperform tasks specific to the client hardware, as well as being thebasis for the windowing structure. Note that the quasi-OS executes noapplication logic and can not load or run any client user processes.

[0108] Since these specialized clients require no conventional CPU orOS, they are inexpensive to produce and sell, and are far more robustthan conventional general purpose PCs. Since these clients offer alonger useful life than general purpose PCs, or other desktopworkstations, the cost of the client may be amortized over longerperiods of time, further decreasing the overall cost of the client.Faster CPUs and extra memory are not required in the specialized clientssince even when service applications become more complex, theapplications are still run remotely on the corresponding server, insteadof being loaded and processed on the client.

[0109] Further, since the client station does not need to containspecific conventional OS platform, the applications running on theservers only need to be concerned with using a standard Internetprotocol, such as tcp/ip and OSSI higher-level protocol for the commandpackets. Thus, the only compatibility required between each client andthe server application is file format compatibility. As will bedescribed hereinlater, since the data in the client file system willtypically be created by the application itself, compatibility is not aconcern.

[0110] Now, instead of a software vendor selling different versions oftheir application programs to run on the different available platforms,only one version is typically resident on a server. Since theapplications are compatible with the client file system (in fact, theapplications do not need to know the internal structure of the filesystem since the quasi-OS will handle the interface) and the quasi-OS,any specialized application will operate with the client, such that anunlimited number of different applications could be accessed by fromeach client connected to a server or to multiple servers. The client canserve its peripheral devices to any number of service applications(according to their commands), and to any number of specialized servers.

[0111] Such inventive servers can have different hardware architectureswithout concern for what OS the clients are running or what devices theyuse. Therefore, software vendors have complete freedom to designmachines and software for maximum speed and flexibility. In fact,servers may not run any OS at all but run directly bootable serviceapplications. The software vendors also will not have to deal withcompatibility concerns, save tcp (or udp)/ip and X11 protocols. By usingOSSI compatible libraries, the software is automatically compatiblewithout any source code modifications.

[0112] Each client need only comprise one or more storage devices, suchas a hard, floppy, or CD-ROM drive. As stated, each client preferablyalso comprises a file system. The client storage system may also beseparate from the client (not shown) by use, e.g., of an attached fileserver. If the client does not have any storage device attached, thenthe only applications which can be used are those which required nostorage facilities, such as html browsers. The files in the file systeminclude a configuration file or database which tells the client quasi-OSwhere on the network (LAN or WAN/Internet) to connect and to which portto obtain a connection to a specific service application. Further, thefile system includes data files storing data corresponding to eachpreviously spawned application, as well as check-point filesrepresenting the state of the program when the connection is terminatedfor each application. Check-point data can generated on a regular basisbased on time, by events occurring on a client station, if theapplication idles for too long, etc. . . . The check-point files allowrecovery in case of network failure, server failure, however, thecheck-point files need to be encrypted by the server to prevent anytampering by the clients. Check-point data can also be used to relocatea client station and then to restore an application which was being usedto the same state it was before such relocation took place. In addition,the file system temporarily stores any work-space files that the serviceapplication may require.

[0113] Accordingly, all of the client user's data, corresponding to eachspawned application, is stored locally to the client station, such thatwhen the client station is disconnected from the network, the user'sdata is incorruptible by anything else on the network. Compare this tosystems wherein the data is stored in a central server file system. Inthose systems, the data is subject to corruption by malice or mistake.

[0114] Further, each client also includes low-level graphical interfacelogic(or at least some user interface) so that the client user canselect which server applications to launch. This non-general purposeclient performs no high-level logic functions. Preferably, the onlyfunctions permitted would include directing the peripheral devices toattach to requesting service applications, making data backups,displaying, and opening, renaming and deleting data files, but would notinclude any processing of such -files. File maintenance operationsshould be embedded within the quasi-OS and perform only pre-determinedwell defined tasks. File maintenance operations, built into thequasi-OS, can not be initiated by any remote service application butrather may only be invoked directly from the quasi-OS by the clientuser. File maintenance may, however, be performed by the servers to theextent permitted by the quasi-OS without involving its internalmaintenance functions.

[0115] Each client station may optionally contain plug-in I/O modulessuch as a frame grabber, an audio/video interface, a digital-to-analogand analog-to-digital converter, a microphone, a camera, a compressionboard., a temperature probe, a humidity probe, an encryption chip, orany other device, as desired. The server then, via the applicationprogram, controls the clients's I/O devices (as well as the client'sfile system, etc.) by sending appropriate command packets to the clientquasi-OS. The client station is able however, to choose which commandpackets would be processed and which ones rejected. Further, as stated,each server may include any specialized hardware for running itsapplications or services without compatibility concerns with the client.

[0116] For example, a movie editing server may include all of theexpensive hardware editors connected to the server. A movie studio maythen have a client station, having a video camera I/O device. The filmor the camera can then be edited via the editing hardware on the serverwithout having to purchase their own expensive editing hardware. Thus,the application would control the data feed from the camera, edit thetransmitted date on the resident editors, and transmit back the editeddata to the client for storage on the client's disk for immediatedisplay on the client's monitor, or for printing on the client's printeror for output to a CD-ROM, a DVD disk or a video tape.

[0117] The operation of the inventive system will be described belowwith reference to the flow chart of FIGS. 3A and 3B. However as aprecursor, note that the client acts as a window on the world for theselected applications, while the client user selected application runson the corresponding server. In other words, the client is a“human-machine-interface” (HMI) for the servers. Upon authorization, theapplication accesses the client's file system to retrieve the user datafor processing. Note that the application controls all of the operationsand controls all of the peripheral devices on the client, via thequasi-OS.

[0118] For example, all of the I/O modules (such as a floppy drive) arecontrolled remotely by the server application. Once the application iscomplete or during the run of the application (as data needs to be reador written), the processed data is transmitted to the client file systemfor local storage on the client. Since the application's program codedoes not get transmitted to the client (like in JAVA or ACTIVE-Xobjects), the user can not copy the code. Accordingly, software vendorscan easily go into China, Hong Kong, Korea, Eastern Europe and othermarkets where software piracy is wide-spread (as high as 98%) and offerthese compute services without piracy concerns.

[0119] As stated, the inventive system differentiates between data andprogram code, i.e., the client file system is intended to store onlydata for the remote server, never their application program code. Theprogram code is loaded into the servers from their own private filesystem (inaccessible to clients) or from a corresponding file server(whose function is limited to carrying the program boot code but can notrun the application) for added security. The only exception to thisseparation is when executable files are themselves program data as in asituation where the application is a compiler (or linker), but thecompiler-server would be cross-compiling for a different architecture.The resulting programs can not run on the client and should not be runon the compile-server (for security). Rather, the resulting programshould be run on a separate execute-server which has the appropriate CPUand software to remotely load and run the program. In general, note thatthe server that runs the application should be different from the serverwhich created it. An execute-server should be able to accept programcode over a network connection and load this program code in its memoryfor execution.

[0120]FIGS. 3A and 3B show a flow diagram providing the steps foraccessing and spawning a server application from a remote client. Atstep 20, a client station is powered on which initializes the network,the user interface, and the file system modules from ROM. The networkmodule initializes the communication interfaces, such as for an attachedmodem, ethernet, ATM, cable or fiber optic connection. Further, amultiple network interface may be available to the client, i.e., theclient may use an ethernet system for the intranet but a cable modem forthe Internet. Servers may be accessible simultaneously through allavailable interfaces. If one of the interfaces is a regular modem, thena telephone connection is made with the ISP to establish a connection.PPP, SLIP or other point-to-point, transport protocols can be used. Theuser interface modules initialize the display, keyboard and the like.The file system module initializes the file system comprising theservice application information (previously spawned applications,networks, servers and ports) and related program data stored on theclient storage device.

[0121] At step 25, the client detects whether any new hardware ispresent. Such hardware includes any added peripheral devices discussedabove. If any new hardware is detected, a corresponding device file iscreated in the file system for controlling the device at step 30. If nonew hardware device is detected, the process precedes to step 35 wherethe client makes connections to all the servers and applications whichhave been stored in its resource configuration file/database.

[0122] At step 40, if the application location (i.e., server IP addressand port) which the user wants to spawn was not previously stored in theconfiguration file, then the client user creates a new entry in the“config” file, at step 45, to include the server and application address(port). However, if the desired application entry is present in theresource configuration file, the client connects to the appropriateaddress to connect to the selected server, at step 50. If theconfiguration file is not present, then the client user has to enter theappropriate IP address and port by hand. Once entered, this informationcan be saved for future use in the configuration file.

[0123] At step 55, the server is authenticated against a trusteddatabase. Simply put, the server may be authenticated by transmitting apredetermined data string. At step 60, if the authentication of theserver fails, then the connection to the server will not be made, atstep 65, and the process returns to step 35, where the client quasi-OSwill try to connect to other servers/ports in the config file or theclient user may select a different server application by hand after allthe entries in the config file are exhausted.

[0124] At step 70, the client receives a public key from the server forencrypting the client's own private key and transmits the encryptedprivate key to the server. The server then decrypts the receivedencrypted private key with its own private key.

[0125] Thereafter, all communications between the client and server aresecured by using the client's private key. The client may generate a newkey every time the client connects to a server or generate several newkeys during a single connection for extra security. Special encryptionhardware such as diodes could be used to generate random bit patterns tobe used as the client's private keys.

[0126] At step 75, the server or a linked directory service applicationtransmits graphical icons to the client representing the server'savailable applications. The client then dynamically builds a windowcontaining each application icon. If, however, no icon is transmittedfrom the server (one is not available), then the client will generate ageneric icon for selection purposes. At step 80, the client user will“click” the desired icon to spawn the corresponding application program.An application can also be started by “dragging” a data file and“dropping” onto the application icon. The client user may also directlyaccess an application by typing in a unique service name at the commandprompt, which is then looked up in the client's resource configurationfile/database and the client then requests the directory service on thecorresponding server that the respective application program is spawned.

[0127] At step 85, it is ascertained whether the server applicationrequires access to any data client files in the client file system. Forexample, if the client connected to (spawned) a word processingapplication for editing, then the application would require the textdata stored locally in the clients file system. If the application doesnot required any access to the client files, then the service continues,at step 90, until the user is done. During the service, the applicationmay also control the client's peripheral devices via the quasi-OS, aspreviously discussed. The application normally receives the file namesit needs to use from the client user as parameters or it is enteredinteractively by the client user after the application was spawned.

[0128] If the application does require access to the client files, it isascertained whether the server application has the authorization toaccess such files (even if the client user entered the file name byhand, the authorization step is still required to prevent the serverfrom changing the file name), at step 95. Such authorization can be setup previously by the client user as a “rule” based permission system togrant authorization to a specific server every time (or until the clientchanges the authorization) or to grant authorization per single use. Arule based restriction may be based on the data file type, theapplication, the server, the access requested and the date. In addition,access by a specific application may be restricted to only a specificset of files by name or directory. Thus, every time the client accessesthe server application, the client user would have to re-authorize suchaccess. Even if authorization is granted to a server, there aredifferent authorizations which may be given to each server. For example,anyone or all of the following authorizations may be given: “read”,“write”, “append”, and “create”, etc. . . .

[0129] If the server does not have authorization to access the files inthe resource configuration file, then the process proceeds to step 100where the client user, as stated above, chooses whether or not to granta single use authorization. If the client user does not grantauthorization, then the process proceeds to step 90 where the servicewill continue until done or the server application may decide toterminate. If the client does grant temporary authorization or theserver/application had a predetermined authorization, then the processproceeds to step 105 where the server application is permitted to read,write, append, rename, move, or create the corresponding file in thefile system, as authorized by the client user. The client also has anability to substitute one file for another. If the file requested by theapplication contains information which the client user does not wantaccessed, the user may substitute another file for it and theapplication will not know anything about the switch. This will allow theclient to “remap” file names which have been hard-coded intoapplications.

[0130] During the service, the quasi-OS may react in three differentways to application's request to perform a particular operation: 1) itmay perform the operation and notify the application of success, 2) itmay not perform the operation and notify the application of failure, 3)it may not perform the operation but still notify the application ofsuccess. The third option would be useful to allow the remoteapplication ,whose “commands” are either inappropriate or violatesecurity to proceed without immediate failure.

[0131] From step 105, the process proceeds to step 90 where the spawnedapplication will continue running until the client user is done. Lastly,at step 110, the processed data from the server application will betransmitted, if necessary, to an appropriate file in the client's filesystem. If the application was updating the data file as it ran, thenthe file would simply close.

[0132] Referring to FIG. 5, the inventive system comprises of twofunctionally distinct blocks: user console device/block 1 andcomputation/application CPU block 2′. The two functional blocks areconnected by a communication interface 13′ which can be a bridge, bus,LAN, WAN, wired or wireless network.

[0133] The functional unit 1′ comprises of a controller 14′, randomaccess memory 5′, user interface devices 3′, storage devices 4′, specialpurpose and IO devices 7. All the components of this first functionalblock 1′ are connected by a bus 6′.

[0134] The functional unit 2′ comprises of at least one processor 8′with some memory 10′ connected either by a local bus 12′ or MMU. Otherprocessor/memory combinations 9′ are also part of the computationalblock 2′.

[0135] The functional unit 1′ also has a connection through thecommunications bus 13′ to communications interface 11′ to remoteprocessors.

[0136] Each CPU 8′ or 9′ may have to be of differing processorarchitectures and may simultaneously run different applications.Applications executing on the computational block 2′ on any of theprocessors 8′ and 9′ utilize, through communications bus (interface) 13′storage 14′, special purpose devices 7′, user interface 3′ bycontrolling controller 14′. Controller 14′ utilizes memory 5′ for itsoperations but memory 5′ is not directly accessible by applicationsrunning on computation block 2′, nor is it directly accessible byapplication running remotely through interface 11′.

[0137] Communications bus 13′ is able to accept a finite number ofindivisible primitive commands, each command performing a specificfunction to control some part of the user console block 1′, to retrievedata and store data from and to storage and special purpose devices.User console block 1′ is able to restrict which primitive commands areperformed on behalf of any application/processor depending on dataprovided to the primitive commands and depending on which application isrequesting access as well as any other parameters which may be set by auser.

[0138] Applications running on remote CPUs and attached to user console1′ via communications interface 11′ and applications running on CPUs 8′,9′ use identical primitive commands to access operating system servicesof user console 1′.

[0139] CPUs 8′, 9′ may load operating system software, needed to run andmanage application processes, from storage devices 4′ of the userconsole block 1′. CPUs 8′, 9′ may also load application program codefrom user console block 1′ storage device 4′. In other words, userconsole block may inject both operating system code and application codeinto local CPUs 8′, 9′.

[0140] User console block 1′ and CPU block form a reciprocalclient-server architecture as described above.

[0141] Referring to FIG. 6, User console kernel (2′) has access to andcontrols stored data (1′) as well as is able to read or write data (3)from or to devices accessible from the controller where user consolekernel (2′) is running. Process kernel (5′) is able to communicate withuser console (2′) through the operating systems services interface (4′).Operating system services interface (4′) includes a finite set ofcommands which it understands. Process kernel (5′) loads and managesprocesses (applications) as well as arbitrates access to user consolepart (2′) between various processes it runs. User console kernel mayrestrict processing of various logics which are part of said userconsole kernel depending on any data which a user may choose, i.e. date,file type, security requirements, application, network, network address,etc. User console kernel (2′) and process kernel (5′) do not share eachother's memory and can not access each other's memory except through theprimitive operations of operating system services interface (4′).Process kernel (5′) does not have access to either stored data (1′) orto device data (3′) except through operating system services interface(4′). Process kernel (5′) may also be able to access stored data (1′) toretrieve stored application code to run said application code underprocess kernel (5′) and access data (3′) and stored data (1′) of userconsole kernel (2′) by using primitive operations of operating systemservices interface (4′).

[0142]FIG. 8 shows communications means (1′), check-point storage device(2′) or (3′), parts of network application program (5′) and (4′). (4′)represents one or more distinct parts. From time to time, with theperiod determined by a user or by an application itself, various partsof a network application (5′) and (4′) examine their own state. Afterthe current state of each part of a network application has beenexamined, a check-point data structure or file is prepared and storedeither in some location connected directly to the network file (2′) orone part of a network application (5′) can collect all the check-pointdata from other parts of a network application and store all thecheck-point data in storage location (3′) to which only this particularapplication part (5′) has access. An application part (5′) usescommunications media (1′) to obtain all the check-point data from otherparts of the application (4′). Before check-point data can be collected,various parts of an application (5′) and (4′) have to be synchronized tobe in a well-defined communications state, i.e. when the application isrestarted from check-point files some applications parts should not beahead of other applications parts. Besides being triggered by timers,check-point data collection can also be triggered by other events likeuser input (if a user wants to force check-point data collection) or itcan be triggered by failure of communications or other events.Collection and management of checkpoint data can also be managed by aspecialized program/server dedicated to management of check-point data.For example, (5′) can be that specialized server instead of anapplication part.

[0143] In a reciprocal client-server architecture setting check-pointdata is collected by the client station program (let us say (5′)). Anapplication program (4′) running on an application server can collectcheck-point data of its internal state at regular intervals of time andany time some special event takes place like user station sending asignal to cause check-point data collection. Then said application (4′)communicates with the user station program (5′) to preserve thecheck-point data within said user station. User station (5′) can alsopreserve check-point data in storage not directly coupled to it, i.e.user station can store the check-point data in storage (2′). Anapplication (4′) can also be forced to collect its internal state databy the server OS/manager if the application is idle and the server needsto conserve memory and CPU resources for other users. In case theapplication is suspended because it is idle it could then be suspendedor removed from memory. Later the application (4′) could be restartedfrom the check-point data in exactly the same state as when it wasremoved. Once the idle application is removed from the server computerit no longer is able to use the server computer resources until theapplication is restarted again.

[0144] While several embodiments have been chosen to illustrate theinvention, it will be understood by those skilled in the art thatvarious changes and modifications can be made therein without departingfrom the scope of the invention as defined in the appended claims.

I claim:
 1. A computing and communication device, comprising: a set “A”of processing element(s) with at least one processing element containingapplication-independent data processing logics therein; a set “B” ofprocessing element(s) containing at least one processing element capableof executing application logics therein; at least one interface betweensaid set “A” of processing element(s) and said set “B” of processingelement(s); wherein said interface includes a means to enable saidapplication logics to interact with said application-independent logicsto do at least one of obtaining data and controlling functioning of saidset “A” of processing element(s) by application logics contained thereinsaid set “B” of processing element(s).
 2. System of claim 1, whereinsaid application-independent logics are digital signal processinglogics.
 3. System of claim 1, wherein said set “B” of processingelement(s) further has at least one communications interface.
 4. Systemof claim 3, wherein said set “B” is able to use said at least onecommunications interface to load application logics.
 5. System of claim1, wherein said set “A” has means to do at least one one of input datafrom and output data to the physical world outside of said computingdevice.
 6. System of claim 1, wherein said at least one processingelement contained in said set “A” is optimized to processes saidapplication-independent logics.
 7. System of claim 1, wherein saidapplication-independent logics are optimized to be executed by said atleast one processing element of said set “A”.
 8. System of claim 1,wherein said application-independent logics cannot be changed by saidapplication logics.
 9. System of claim 1, wherein said set “A” has meansto restrict access to said application independent logics.
 10. System ofclaim 1, wherein said set “A” has means to associate a particular subsetof said application-independent logics with particular applicationlogics and to restrict access by said application logics to said subset.11. A method of converting a conventional application program, which isdesigned to interact with a particular operating software and hardwareplatform, to a network application service program which communicateswith at least one client device via a standard service interfacecommunications protocol, comprising the steps of: replacing actions ofcode, said actions designed to interact with said particular operatingplatform, of said conventional application program with actions forgenerating command data packets using said standard service interfacecommunications protocol, without modifying application logics of saidconventional application program, to convert said conventionalapplication program to said network application program, so that anapplication server is able to transport said command data packets tosaid client device for controlling at least one of specific operatingsoftware or device operations of said client device; wherein saidnetwork application program runs within an application server, accessesdata of said client device, and is able to control at least one ofspecific operating software or device operations of said client device,when said client device connects to said network application program, asrequired by said network application program logics.
 12. Method of claim10, wherein said at least one client device has means to restrict accessto said at least one of specific operating system or device operationsof said client device.
 13. Method of claim 10, wherein said replacementsof said actions take place during at least one step of applicationservice program life, i.e. pre-processing step, compiling step, liningstep, executable code post-processing step, process loading step, orapplication program process run-time step.
 14. A method of securelyaccessing application services from at least one application server,comprising the steps of: accessing at least one application server by atleast one client device to connect to said at least one applicationlogic on said at least one application server; wherein said at least oneclient device has application-independent logics stored therein and atleast one controller for controlling said application-independentlogics, said application-independent logics including at least one of auser interface logic, a device control logic for controlling devices, afile system logic, and a communications interface logic; and whereinsaid at least one application server has application logic stored in aserver device coupled to said at least one application server, forexecuting said at least one application logic; having said oat least oneapplication server selectively interact with saidapplication-independent logics to retrieve data corresponding to said atleast one application logic from said at least one client device uponoptional authorization from said at least one client device; processingsaid corresponding data on said at least one application logic. 15.Method of claim 13, wherein said at least one client device is unable toread or copy the code of said at least one application logic.
 16. Methodof claim 13, wherein said at least one application server is ableprocess data of said at least one client device without having topermanently co-locate said data corresponding to said at least oneclient device with said at least one application server.
 17. A securemethod for managing devices, and/or data storage systems of at least oneclient device, comprising steps: at least one application server havingapplication logic stored within a server device coupled to said at leastone application server for running at least one management applicationprogram, and said at least one application server being capable ofaccessing multiple devices and data storage systems, each coupled to atleast one respective client device, when each client device interfaceswith said at least one application server to access said at least oneapplication program; wherein each interfaced server selectively accessessaid devices, said storage systems or both to form a centralized deviceand storage management system for controlling and accessing devices,storage systems, states, or configurations of said at least one clientdevice; wherein upon accessing by said at least one client device, saidat least one application server runs at least one application programand selectively controls application-independent logics of said at leastone client device for controlling devices of said at least one clientdevice and for manipulating data of said at least one client device; andwherein said at least one application server is able to process saidcorresponding data of said at least one client device on said at leastone managing application program.
 18. Method of claim 17, without saidat least one application server having to permanently store said data ina server device coupled to said at least one application server orwithin said application server.
 19. Method of claim 17, wherein saidapplication logics can be accessed and interacted with by at least onemanaging client device so that said at least one managing client deviceis able to control and access application-independent logics of said atleast one managed client device via said at least one applicationserver.
 20. Method of claim 17, wherein different client devices may usedifferent communication protocols to interface with said at least oneapplication server.